Feb 1996 Enterprise Windows

by: John D. Ruley

What IS an enterprise section doing here in WINDOWS Magazine? Telling you all about emterprise hardware and software, of course! Windows has had built-in networking features since the introduction of Windows for Workgroups more than two years ago. Since then, the Windows NT operating system has extended Windows networking beyond the desktop realm into areas never before explored by Windows. And wherever Windows goes, WINDOWS Magazine will follow to fulfill our promise to be your one-stop source for essential Windows information. But we won't limit ourselves to covering only Microsoft's Windows-based enterprise networking solutions. There's more to networking than Windows in isolation, and so this new section will cover more than just Windows alone. Take our own in-house editorial network as an example. We run a decidedly mixed environment that currently includes two Novell NetWare 3.11 servers, several NT Servers, an OS/2 1.3 Server (which we are planning to switch over to NT this year), and a mix of Windows for Workgroups, Windows 95, NT Workstation and (gasp!) even Macintosh client systems. Beyond the editorial net, we're connected to an enterprise network at CMP Media (our parent company) that includes a mix of NetWare and UNIX servers--the latter serving as our corporate Internet gateway. This kind of network is common (even pervasive!) and isn't about to go away. Readers use a wide variety of networks and protocols. Enterprise Windows reflects this reality--it's about Windows-oriented computing in the real world, where the enterprise administrator (a very busy person) has to manage disparate clients on a multivendor network. Enterprise Windows is Windows-centric, and this month you'll find articles covering NT as a CAD workstation platform, 32-bit word processor and spreadsheet compatibility with NT and Windows 95, OpenGL 3-D video boards, and NT Server log-in scripts. You'll also find a pithy--and insightful--column on integrating NT and NetWare by our very own "enterprise administrator," Tom Henderson. In future Enterprise Windows sections, you'll find coverage of network backup software and hardware, NT Server's new software router, database servers and more. If it relates to implementing and maintaining Windows-centric networking, it's fair game for this section. And now a blatant plug: In case you weren't aware of it, WINDOWS Magazine has had a dedicated NT column since 1992. In this issue, you'll find some educated guessing at the size of the NT installed base and detailed instructions on how to get Internet access from just about anywhere via CompuServe. Please forgive me for plugging that column--it happens to be mine!

by: Ranjit Sahai

Visit the Department of Transportation at your local state offices, and you probably will find its engineering department running technical applications, such as those for roadway design, on UNIX workstations. But the winds of change are blowing in favor of Windows NT-based workstations. "With over 50 workstations for our engineering application users, we have been a UNIX shop for nearly a decade," said Maryland State Highway Administration's (SHA) Jim Yarsky. However, eight months ago he started replacing his UNIX systems with Windows NT-based workstations. He expects most UNIX workstations at SHA will have been replaced with Windows NT workstations by the middle of this year. Yarsky isn't alone. The availability of Windows NT versions of many specialized technical applications that previously supported only UNIX is driving the migration to Windows NT. Whether Intel's P6-based systems interest you for PC compatibility reasons, or you value the raw processor speed of Digital's Alpha AXP RISC processor, today's hottest hardware supports Windows NT. To see how well technical applications run under Windows NT, we decided to test a 150MHz dual Pentium Pro-based workstation and a 275MHz Digital Alpha AXP processor-based workstation. We ran native versions of both AutoCAD and MicroStation, the two leading CAD (computer-aided design) applications for the technical market, and tested their performance on these systems from a user's perspective. We also ran WINDOWS Magazine's benchmark program, NTHell 2.0, and GLperf (an OpenGL graphics benchmarking program) for gauging the two systems' relative performance.

The dual 150MHz P6-based TDZ-400 is Intergraph's latest entry to its TD (Technical Desktop) line of personal workstations. The system tested came configured with 64MB of RAM, a 2GB Fast SCSI-2 hard drive, GLZ1T graphics accelerator card (Intergraph's own 3-D OpenGL hardware accelerator with 20MB of memory) connected to a boot-up Super VGA card on the motherboard and quad-speed CD-ROM drive. The system also features sound and Ethernet integrated onto the motherboard. An innovative keyboard with built-in speakers, a three- button mouse and a 21-inch monitor round out the system, which carries a $19,500 price tag. Rather than using Intel's motherboard design, Intergraph decided to develop its own motherboard tuned for graphics performance. The accompanying high-quality, comprehensive documentation was specifically written for the system. Though the system comes preloaded with DOS/Windows and Windows NT Workstation 3.51 in a dual-boot configuration, it is the latter that exploits its dual-processor design. If you will be integrating it in a UNIX environment, you may want to consider an optional NFS (Network File System) that supplements Windows NT's built-in TCP/IP support.

Instead of an Intel CPU, this system uses Digital's Alpha AXP processor with a blazing 275MHz clock speed. The system I tested came configured with 64MB of RAM, a 2GB Fast SCSI-2 hard drive, AG300 display adapter (an OpenGL hardware accelerator with 7.5MB of video RAM) connected to Number 9 Corp.'s GXE adapter for boot-up support, and a Plextor 6X CD-ROM drive. The system also features a Fast Ethernet network card, a two-button mouse and a 21-inch monitor. It sells for $16,500. The BTG AXP is built upon Aspen's Alpine motherboard and uses standard PCI-bus components. The system documentation provided is a thin, generic manual common to all of BTG's AXP models. Component booklets are also included, complete with DOS driver disks the system cannot use. Windows NT Workstation 3.51 for the Alpha processor comes preloaded.

Digital's Alpha AXP is the fastest processor system manufacturers can buy today. The BTG AXP Ultra is a single processor system. The Intergraph TDZ-400 uses dual Intel Pentium Pros. Whereas the AXP offers greater raw speed, the TDZ can spread its computational load between two processors. When you concurrently run multiple applications, or run a single multithreaded application, the single AXP services the various processes by dividing time among them. In contrast, the TDZ can service separate processes on separate processors. While AutoCAD Release 13 is not multithreaded, MicroStation 95 implements OLE Automation as a separate thread and is also capable of spawning off a separate display thread when it detects multiple processors. AutoCAD Release 13 and MicroStation 95 performance on both the AXP275 and the TDZ-400, when not exploiting their OpenGL hardware through special drivers, is up to four times faster for file opening and rendering operations than a 60MHz Pentium system. And when Mogle or AutoGL are activated, performance is up to 30 times faster.

The time difference for opening the same drawing on both systems was not significant and depended on the CAD software being run. AutoCAD was slightly faster on the AXP, and MicroStation was slightly faster on the TDZ. It took 2 seconds to load the AutoCAD kitchen drawing on the AXP and 2.5 seconds to load on the TDZ. Loading the MicroStation living room drawing on the AXP took 8.5 seconds, compared to 7.5 seconds on the TDZ. MicroStation performed better on the TDZ because it started a separate display thread when it sensed that there were two processors. Rendering without the OpenGL drivers, whether done in AutoCAD or MicroStation, was faster on the TDZ. The AutoCAD kitchen drawing took 4.5 seconds to render on the AXP and 4 seconds on the TDZ. The MicroStation living room drawing took 38 seconds in Version 5.0 and 29 seconds in Verson 95 on the AXP; it took 27 seconds and 15.5 seconds, respectively, on the TDZ. Consistently better rendering performance on the TDZ seems to indicate a better video subsystem design. As noted earlier, Mogle and AutoGL are drivers developed by Intergraph to better exploit 3-D accelerator hardware. As of this writing, both drivers were available only for the Intel platform. Enabling these drivers makes a dramatic difference in rendering times in both applications. For instance, an AutoCAD drawing rendered up to six times faster with AutoGL. Similarly, a MicroStation drawing rendered 6.5 times faster with Mogle. Although Mogle and AutoGL can be run on systems without OpenGL hardware, you will not see such dramatic performance improvements. However, these drivers add the convenience of dynamic pan and zoom, regardless of your video hardware or whether you're creating 2-D or 3-D drawings. Though you will need to depend on third-party OpenGL drivers for AutoCAD Release 13 and MicroStation V5, MicroStation 95 includes the msopengl.ma driver as standard fare. Type "mdl load msopengl" in MicroStation's key-in window to load it, and turn on the Graphics Acceleration check box in the Rendering View Attributes dialog box to enable it. Performance gains similar to those provided by Mogle were observed. However, MS-OPENGL does not support material-mapping (compare the material mapped brick wall and the plain white wall in the two living room screenshots) in the late beta of MicroStation 95 I ran.

In addition to the application tests discussed above, I also ran NTHell 2.0, WINDOWS Magazine's benchmarking software, and GLperf, OpenGL's benchmarking software. NTHell tests performed included measuring the floating-point calculation performance, memory data-transfer speed, disk data-transfer speed and OpenGL performance. The floating-point calculation speed, as measured in millions of Whetstones per second, on the AXP was clearly faster, 181.8 vs. 80.0. Memory data-transfer speed, measured in MB per second, was slightly faster on the TDZ, 149.4 vs. 136.5. Disk data-transfer speed in MBps was marginally faster on the AXP, 17.64 vs. 17.26. OpenGL performance, as measured by the time that was required to display a test image, was clearly faster on the TDZ, 4.74 seconds vs. 1.05 seconds. The better OpenGL performance on the TDZ was also borne out by the GLperf benchmark software. GLperf tests performance by bombarding the screen with a variety of primitive graphics elements such as points, lines, triangles and line strips in gradually varying colors. The TDZ completed the test in a total of 4 minutes 35 seconds, as opposed to a considerably longer time of 7 minutes 19 seconds on the AXP.

Windows NT is a portable operating system available on various hardware platforms. If clock speed alone were to be taken as the measure of system selection, the BTG AXP275 would be a natural choice. But the availability of applications and their performance are more realistic selection criteria. In the short time I've tested the systems, I've grown to favor the TDZ because of its sleek trimline case, much lower noise level, integrated sound, better 3-D rendering performance, and above all, availability of a much larger AutoCAD and MicroStation add-on selection to address discipline-specific needs. Softdesk, the largest AutoCAD third-party vendor, is already shipping its line of civil, structural, mechanical, imaging, plant-design and facilities-management applications for AutoCAD on Intel NT, but is "looking carefully" at porting them to Alpha NT. The MicroStation side had a better response towards Alpha NT. Geopak and IdeaGraphix (a Soft- desk company) expect to ship Alpha NT versions of their civil and architectural applications, respectively, by the time you read this. However, applications for Alpha NT from smaller vendors may be much longer in coming. If you're migrating from the UNIX platform, you're likely to cherish the abundance of Windows NT-compatible software. Windows' support for interapplication communication means that you can have the results of worksheet computations drive your CAD software to generate graphics. Additionally, if you miss the powerful UNIX command shells, such as Korn shell or C shell, don't despair. The Hamilton C shell for Windows NT is available on all NT platforms, as is the MKS Korn shell.

by: Ram Tackett

by: Richard Furnival

Network administrators traditionally refer to any command list executed when a user logs into a network as a log-in script. In an NT Server network, log-in scripts are usually nothing more than simple batch files. Limited decision branching is available for batch files. Anyone familiar with log-in scripts in a Novell NetWare environment may wonder how an NT administrator tolerates this limitation. However, with a little ingenuity and a small toolbox of utilities, an NT administrator can accomplish any required log-in initialization sequence.

Because most networks comprise many client systems, your log-in script must possess some intelligence to decide which commands are appropriate for which clients. Also, most networks need to be set up so that a user may log in from nearly any workstation. Multiple operating systems (DOS, Windows 95, Windows 3.x, Windows NT and OS/2) can challenge the NT administrator because many commands are not cross-platform compliant. The following sample log-in script performs all these tasks, regardless of the operating system.

On a Windows NT network, certain minimum requirements exist for centrally stored log-in scripts to execute. First, NT Server is required as the log-in processor. Second, an NT domain installation must exist on the network, and a Primary Domain Controller (PDC) must validate each log-in event (workgroup servers do not support centralized log-in scripts). In addition, a user account with a log-in script specified via the NT Server User Manager utility is required. Most NT administrators will want to specify a user's home directory for network use--which is accomplished with User Manager's Profile feature. Also, to prevent every user's home share from appearing in the server's browse list, add the "$" character to the end of the share name. For example, net use h: \\server\home$ connects to an administrative share that's invisible to most users. The script file named in the user account must be in the NETLOGON share directory (typically, %SystemRoot%\System32\Repl\Import\Scripts) on the domain controller. When the domain controller has met all these requirements, and the client is configured for a domain-based log-in, the specified log-in script is downloaded to the client and executed as if it were present on the local system.

A few programs can support the log-in process and help the administrator deal with the various network clients. Some are standard Windows networking commands, while others are third-party programs now in the public domain. The first, and most powerful, command is NET.EXE and its related subcommands. NET.EXE is a standard command, available in various forms on all Microsoft and OS/2 networking platforms. There is limited documentation available for this command. However, issuing Net Help in an NT console window will get you on your way fully understanding this handy tool. The second program, PUTINENV.EXE, is a freeware program written by M.J. Winkler available as PUTENV.ZIP in Lib 22 of the WINNT forum on CompuServe. Use this utility to obtain LAN Manager (NT's predecessor, an OS/2-based network operating system previously sold by Microsoft) information from the network. All the user-specific environment variables required to perform decisions within a batch file are obtained using PUTINENV.EXE when non-Windows NT clients are used. The last two programs, SETW.EXE and WINSET.EXE, are used to modify the system environment on computers running Windows 3.x and Windows 95, respectively. Both are unsupported, use-at-your-own-risk software from Microsoft. SETW.EXE is part of a program called KIXTART that's downloadable from the World Wide Web at: http: // www.xs4all.nl/~akhw/winnt.htm. WINSET.EXE can be found on the Windows 95 CD-ROM in the Admin\AppTools\EnVars directory. A readme file is also available for specific details on either program. Depending on your network clients, you may need one or both of these utilities. As discussed earlier, all scripts are executed as if they were local to the client. That's why it's a good idea to have any supplemental programs located in a directory that is present in the local system PATH environment variable. According to documented information, placing them in the NETLOGON directory should suffice, but this technique has proven to be unreliable in testing.

Before finding SETW.EXE, I struggled to find a way to modify the environment of a computer running Windows 3.x. There seemed to be no way to change the environment of the so-called "system VM" (virtual machine) on these computers. SETW performs this task in fine fashion. WINSET is the Windows 95 equivalent of SETW. This command is a little easier to implement since it does not require any "helper" virtual device drivers as does SETW. It also seems to be very reliable. Both programs are simple to use. They mimic the standard DOS SET command where the command name is entered followed by variable_name=assignment on the command line, in a batch file or log-in script. Clients running Windows NT or OS/2 do not have to resort to all these environmental shenanigans. The operating systems automatically set all required network environment variables during log-in (NT Servers store the variables in the NT Registry, while OS/2 stores them in the CONFIG.SYS file). Temporary variables can be set just as you would in DOS, but their scope extends only for the life of the log-in process.

by: Tom Henderson

t's interesting to watch the fear in NetWare supervisors' eyes when the specter of NT appears on their LANs. Microsoft's BackOffice initiatives have struck many users' fancies, and NT is the foundation of BackOffice. Users see Windows, Office and Mail on their desktop and make an easy leap of faith to BackOffice. Extensibility isn't much of a concern to them because the options look better than ever--with NT they see hot platforms like stereo Intel Pentium Pros, 64-bit Digital Alphas or interchangeable-CPU setups. Most of the questions about dropping NT into a NetWare LAN involve management, connectivity and support. The long-running gunfight between Microsoft and Novell can only be described as one of the decade's premier tests of patience in desktop networking. Jim Allchin, Microsoft's senior vice president of business systems (NT and BackOffice), sees his target market as small to medium-size organizations, not the types with established hosts or enterprise-computing infrastructures already in place. That's the kind of marketing that has popularized desktop and personal computing: Start at the lower levels and work your way up the chain. What makes administrators queasy about all this is that applications servers represent a new hierarchical level of support in their domain, located somewhere between big iron and desktops. Fortunately, most of the early stumbling blocks to integrating NT are gone. Microsoft's unroutable NetBEUI/NetBIOS protocol is finally optional. Drivers are available for nearly every recent network card. You can back up NT through several familiar (and sometimes well-loathed) tape-backup and archiving apps. And RAID drives abound. Network management, however, is still a bit weak. Dropping an NT server onto a Novell network works. It's not foolproof, but it's breathtakingly simple compared to repartitioning a NetWare Directory Service (NDS) partition to add a new NetWare server to the LAN. Therein lies one of the biggest problems with NT on a NetWare LAN--after you've invested time and effort tying your network together under NDS, NT as an applications server delightfully ignores it. As a NetWare client, NT finally has working client software from both Microsoft and Novell (the big guns waited two full years before pulling that particular trigger!). You can have one of three versions: NetWare client, NetWare server or Microsoft's Network Client/Server. Windows NT comes with built-in support for Novell's core communications protocols, IPX and SPX. With Microsoft's new File and Print Services for NetWare add-on, NT also becomes a file and print server that looks to clients just like the NetWare 3.x file and print server (but still doesn't participate in NDS). On the workgroup level, however, Microsoft probably doesn't care--and NetWare administrators shouldn't either. The elevated blood pressure you experience waiting for competing NDS-NT linking software can be hazardous to your health. Until someone puts some charm into UNIX or a variant, NT will be a successful small-organization applications server. Gone are the stumbling blocks to connectivity. No more tearing your hair out over rudimentary management software. Perhaps I'm damning with faint praise when I say NT is as simple to drop onto a NetWare network as Windows 3.x or Win95--but it's certainly no worse. Users don't, and won't, care about the ongoing gun battles. They just want to do their computing with a little elegance, and get on with it.